IBIS Macromodel Task Group Meeting date: 24 May 2011 Members (asterisk for those attending): Agilent: Fangyi Rao * Radek Biernacki Ansoft: Chris Herrick Danil Kirsanov Ansys: Samuel Mertens * Dan Dvorscak Deepak Ramaswamy Jianhua Gu * Curtis Clark Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Celsionix: Kellee Crisafulli Cisco Systems: Mike LaBonte Stephen Scearce Ashwin Vasudevan Ericsson: Anders Ekholm IBM: * Greg Edlund Intel: Michael Mirmak LSI Logic: Wenyi Jin Mentor Graphics: * John Angulo Vladimir Dmitriev-Zdorov Zhen Mu * Arpad Muranyi Micron Technology: Randy Wolff NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: * Eckhard Lenski Sigrity: Brad Brim Kumar Keshavan * Ken Willis SiSoft: * Walter Katz Mike Steinberger * Todd Westerhoff Doug Burns Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla The meeting was lead by Arpad Muranyi ------------------------------------------------------------------------ Opens: - -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None ------------- New Discussion: Arpad asked if we needed further discussion of the Table Syntax Clarification BIRD: - No one replied (discussion not needed) Arpad moved to vote on submitting it to the Open Forum: - Unanimously approved Arpad brought up Items #13 and #14 below: - Arpad: Are we now in a position to proceed on these? - Bob: #13 is taken care of by Table Syntax Clarification? - Arpad: No, 13 refers to a different "table." - Bob and Arpad: brief discussion and decided to defer. Arpad brought up the AMI_BooleanBNF_BIRD draft: - Arpad: Bob has recently sent a new update. - Bob described two slightly different options for the BNF syntax. - Bob and Arpad: decided to defer. Arpad brought up the AMI_CornerRange_BIRD draft: - Arpad: Added new language explaining that AMI slow fast could not be rigorously tied to IBIS concept of typ, min, max. - Todd: Too bad we have to incorporate vague IBIS typ, min, max into AMI portion at all. - Arpad: Perhaps a BIRD clarifying typ, min, max issues for some parameters would help. Is Bob working on such a BIRD? - Bob: We should have discussion of some BIRD topics... - Walter: That is an IBIS issue, we should focus on AMI. - Todd: Not sure the wording could really be improved over what Arpad has provided. Arpad brought up the AMI_ParametersOUT_BIRD draft: - Arpad: Introduced the new language in the draft. - Arpad: Described the cut and paste approach applied to similar parameters in Init and GetWave. - Ambrish: Question relating to **msg description - Arpad: Reviewed the new descriptions of the expected usage for msg and AMI_parameters_out. Arpad brought up the AMI_FunctionReturnValue_BIRD draft: - Arpad: Reviewed the new language in the draft. - This adds the suggestion that models return configuration staus and data. - Return code of (1) means simulation can continue - (0) means simulation should stop. - Todd: Success means the simulation ran (not quality of results) - Walter: Success means the simulation can continue. - Fail means the simulation stops and report the msg for Init or the AMI_Parameters for GetWave. - Arpad: Described the impetus for writing this draft - A customer model returned 0 (fail?) despite the fact that it seemed to run fine. Arpad brought up the Info, Out, InOut BIRD and gave control to Walter: - Ken: Is this [document/presentation] on the website? - Walter: It will be sent out after the presentation. - Walter: It is a presentation proposing a framework in which discussions regarding "compliance" can take place more rigorously. - Greg: You're essentially breaking compliance up into three components: - syntactical - compliant DLLs - compliant results - Walter: Yes, essentially, ... - Greg: Okay, just making sure I understand. - Arpad: Reviewed the contentious "must not" sentence in the original BIRD. - Walter: "must not..." should be replaced by saying "such usage is not compliant" - Arpad: Since we're writing this within the spec, it's implicit that "must not" means "will not be compliant". - "Must not" is not a global prohibition, it only applies to the spec. - Todd: Simply saying "compliance" doesn't really help the end user who wants to know what tools/models can be used to get a particular result. - Radek: How is the user made aware of "compliance" info? - Bob: Arpad's "must not" wording is implicitly saying "is not compliant" because it's in the spec. - Arpad: Showed an example from a "Languages Supported:" section of the spec. - He said that section enumerates the supported languages, and it is implicit that usage of others is not compliant. - Ambrish: Restated Arpad's original language with the substitution of Walter's preferred "is not compliant" in place of "must not" - Todd: We're running over time... - Arpad: I'm willing to change the wording - I just want to be sure everyone thinks we should. Meeting ended. Note - Agenda Items referred to above: 13) IBIS-AMI 6C Tables Update 14) Define relationship between Type and Format. ------------- Next meeting: 31 May 2011 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives